1. Field of the Invention
The present invention relates generally to content aggregation frameworks (such as portals), and more particularly, enables network-accessible applications to be integrated into such frameworks and to become dynamically interactive through proxying components (such as proxying portlets), thereby providing run-time cooperation and data sharing.
2. Description of the Related Art
In recent years, a content aggregation framework based on a portal server model has become the de facto standard for development of web applications worldwide. In this approach, portal applications called “portlets” are used with the portal server.
Portlets are applications that emit markup into an aggregation stream, and have become a popular programming model. In the predominant approach, portlets are run on a portal server. A portal server may aggregate content from a number of these content-emitting applications when creating the aggregation stream. This aggregation stream represents a complete portal page, and this portal page is returned from the portal server to a client for display in the client's web browser. This portal/portlet model is well known in the art.
Portal servers process requests for page content in two phases, an “action” phase and a “render” phase, in that order. In the action phase, all invoked portlets on the page process the request, but do not generate content. It may happen for particular requests that the action phase is omitted, or may be invoked on a subset of the portlets being aggregated. In the render phase, the invoked portlets all contribute their respective chunks of content to a portal aggregation engine that aggregates the content and generates a page in response to the original request. This generated page is then sent to the requesting browser for rendering.
This processing is shown generally in FIG. 1, where a browser 100 sends a Hypertext Transfer Protocol (“HTTP”) request 110 to a portal engine 120. (Portal implementations may be structured with functionally distinct modules referred to generally as an engine and a portlet container, where the engine is responsible for content aggregation and the container is responsible for portlet lifecycle functions that include dispatch of the action and render methods. The term “portal engine”, however, is used in figures and discussions provided herewith as a reference to a combination of these two functional modules.) Supposing, for purposes of illustration, that the requested page requires input from two portlets designated in FIG. 1 as “Portlet A” 140 and “Portlet B” 141, the portal engine 120 then triggers the action phase of those portlets, as shown at 130, 132. After each of the portlets executes its respective processing, it returns content 131, 133 to the portal engine 120 during the render phase. Portal engine 120 then aggregates this content, and sends the aggregated result as an HTTP response 111 for rendering by browser 100.
Portlets adhere to a portlet application programming interface (“API”) that enables their integration into the portal architecture. However, there are a large number of network-accessible applications that were not written to the portlet API, and it is often desirable to include content from these applications in the portal environment. (These non-portal network-accessible applications are referred to herein generally as “web applications”, and may include so-called “legacy” applications which have been made network-accessible.) By surfacing these non-portal applications in a web portal, the portal's aggregation, personalization, and management capabilities can be leveraged.
Rewriting the applications to execute in a portal environment is cost-prohibitive in most cases, and nearly impossible in some cases (for example, where source code is not available). Accordingly, to enable integration of such web applications into the portal, a component referred to as a “generic reverse proxy portlet” may be used. (A generic reverse proxy portlet is referred to herein equivalently as a “reverse proxy portlet”.) A generic reverse proxy portlet, by definition, is a portlet that mediates access to a web application and surfaces the content provided by that application in a portal page. A generic reverse proxy portlet may optionally transform the content it receives from the web application prior to sending that content to the portal's aggregation engine. Generally, a generic reverse proxy portlet is coded without specific knowledge of, or dependence on, the web application it proxies. Such portlets therefore provide an efficient means of surfacing non-portal and legacy application content in the portal environment.
A portal page may contain content created by one or more non-portal or legacy applications (with that content surfaced through their respective generic reverse proxy portlets) and by one or more traditional (i.e., non-proxying) portlets. This scenario is illustrated in portal page 201 of FIG. 2. Again, a browser 100 sends an HTTP request 110 to a portal engine 120. Suppose, for this example, that the requested page again requires input from “Portlet A” 140 and “Portlet B” 141 but now also requires input from a non-portal web application 261 executing on an application server 260. A generic reverse proxy portlet (“RPP”) 242 is therefore used to mediate access to web application 261. When the portal engine 120 receives HTTP request 110 and triggers the action phase of portlets 140, 141, and 242 (as shown at 130, 132, 234), the traditional portlets 140, 141 execute as discussed in FIG. 1. The reverse proxy portlet 242, on the other hand, makes an HTTP request 250 to the web application 261 for its content. Upon receiving the requested content in an HTTP response 251, reverse proxy portlet 242 may apply one or more configured transforms to that content (e.g., clipping off some content, applying rule-based transformation of the content, and so forth). At the least, reverse proxy portlet 242 typically transforms the proxied content by rewriting uniform resource locators (“URLs”) appearing therein so that interactions initiated by the browser will pass through the proxy 242, instead of directly invoking web application 261. (This approach preserves the end user's perception of staying within the portal.) A reverse proxy portlet may also discard headers found in the proxied content to make that content suitable for inclusion in an aggregated portal page. In the render phase, portlets 140, 141 return 131, 133 their generated content and reverse proxy portlet 242 returns 235 its proxied (and transformed, if applicable) content to the portal engine 120. Portal engine 120 then aggregates this content, as in FIG. 1, and sends the aggregated result as an HTTP response 111 for rendering by browser 100. FIG. 2 shows a sample arrangement of the aggregated content in portal page 201, by way of illustration only.
While the scenarios illustrated in FIGS. 1 and 2 provide a number of advantages, portlet users desire not only to see an aggregated result of content surfaced by multiple portlets, but also to have cooperation and interaction among the content of the various portlets. In the prior art, cooperation among traditional portlets is facilitated using techniques that include a manual triggering of a publish/subscribe mechanism and an automated triggering thereof. Each of these approaches will now be briefly described.
Portal servers may provide a publish/subscribe mechanism using a run-time component called a “property broker” that enables traditional portlets to interact with each other by publishing and subscribing to information in the form of typed properties (i.e., typed data items). (This type of brokering support is commercially available, for example, in the WebSphere® Portal product marketed by International Business Machine Corporation, hereinafter “IBM”. “WebSphere” is a registered trademark of IBM in the United States, other countries, or both.) The portlet that publishes a property is called a “source portlet” and a portlet that receives a published property is called a “target portlet”. In a manual approach to triggering of the mechanism, the cooperation between source and target portlets may be driven through a manual “click” operation initiated by the user, whereby the click operation in a source portlet causes that portlet to publish the value of a particular property. The click operation, which is sometimes referred to as “click-to-action” or “C2A”, might be carried out responsive to user activation of a graphical button rendered in the source portlet, for example. Target portlets which have registered their ability to consume the published property receive that property's value, and a predetermined action is then initiated at the target portlet in response. Refer to commonly-assigned and co-pending application Ser. No. 10/448,968, filed May 30, 2003 (now U.S. Pat. No. 7,281,217), for more information on techniques with which this manual, user-initiated cooperation among portlets may be provided. This application, which is hereby incorporated herein by reference, is titled “System and Method for User Driven Interactive Application Integration” and is referred to hereinafter as “the first related application”.
In another approach, an automated triggering of the publish/subscribe mechanism is provided whereby source portlets are “wired” to target portlets through configuration, thereby enabling automated cooperation between portlets. For example, when a source portlet publishes a particular property to the property broker, then all actions on target portlets that have been wired (i.e., configured) to this source portlet are preferably triggered by the property broker. Refer to commonly-assigned application Ser. No. 10/292,074, filed Nov. 12, 2002 (now abandoned), for more information on techniques with which this automated cooperation among portlets may be provided. This application, which is hereby incorporated herein by reference, is titled “Portlet Data Sharing System, Method, and Program Product” and is referred to hereinafter as “the second related application”.
Still another approach is described in commonly-assigned application Ser. No. 10/776,040, filed Feb. 11, 2004 (now U.S. Pat. No. 7,376,739). This application, which is hereby incorporated herein by reference, is titled “Persistence of Inter-Application Communication Patterns and Behavior Under User Control” and is referred to hereinafter as “the third related application”. As disclosed therein, a persistent association may be created between properties published by a source portlet and actions of one or more target portlets. Accordingly, an action on a target portlet can occur in an automated manner, without requiring a user to manually select publication of a property that triggers the action.
In these approaches, the publish/subscribe mechanism allows for cooperation among independently-developed portlets, such that the portlets can share data dynamically and interact accordingly. The usefulness of portal content may be greatly enhanced as a result. Portlets that are capable of cooperating in this manner must interact with the property broker component of the portal run-time. This means that the portlets must be coded to declare, publish, and subscribe to properties with a property broker. Web applications, because they are not portlets, are not coded to carry out these operations with a property broker, and therefore are unable to participate in this portlet-to-portlet cooperation. Accordingly, a need remains for enabling content surfaced by reverse proxy portlets to provide the type of portlet-to-portlet cooperation available for traditional portlets.